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Abstract Recently, XACML is a popular access control policy language that is 
used widely in many applications. Policies in XACML are built based on many 
components over distributed resources. Due to the expressiveness of XACML, 
it is not trivial for policy administrators to understand the overall effect and 
consequences of XACML policies they have written. In this paper we show a 
mechanism and a tool how to analyses big access control policies sets such 
as (i) incompleteness policies, (ii) conflicting policies, and (iii) unreachable 
policies. To detect these problems we present a method using Answer Set 
Programming (ASP) in the context of XACML 3.0. 
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1 Introduction 

XACML (extensible Access Control Markup Language) is an OASIS ^ standard that 
describes both a policy language and a query/response language for access con¬ 
trol policies. It has been used in many different applications range over health 
care information systems, transport systems to banking information systems^. The 
policy language is used to express access control requirements (yvho can access what 
when) over distributed resources and the query/response language is used to query 
whether a particular access should be allowed {request) and to answer the query 
{response). Access control policies in XACML are built based on many components 
and combined using a particular combining algorithm. 

Due to the expressiveness of XACML, it is not trivial for policy administrators to 
understand the overall effect and consequences of XACML policies they have writ¬ 
ten. The problem becomes more prevalent if there are no mechanisms/automated 

^ OASIS (Organization for the Advancement of Structured Information Standard) is a 
non-for-profit, global consortium that drives the development, convergence, and adop¬ 
tion of e-business standards. Information about OASIS can be found at http://http: 
//WWW. oasis-open.org/. 

^ XACML references and products can be seen in https://www.oasis-open.org/ 
committees/download.php/42588/xacmlRefs - VI-85.html. 
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tools to analyse big chunk of policies. Several problems might occur in developing 
access control policies such as incomplete policies and conflicting policies. Moreover, 
detecting unreachable policies might help policy administrators to remove unused 
policies in order to make the set of policies slimmer and make it easier to be main¬ 
tained. 

Analysing Incomplete Policies. It is high probable that policy developers do not define 
all possible situations that might occur. Incomplete access control policies might 
lead to a security problem. Following we present a probable scenario how an in¬ 
truder can use this security hole to get an access. 

In XACML, PDP (Policy Decision Point) computes a decision based on adminis¬ 
trated policies in a database, but the final decision is made by PEP (Policy Enforce¬ 
ment Point). There are two PEP-biased: 

1. Permit-biased PEP: if the decision from PDP is deny, then the PEP shall deny 
assess. All other decisions shall result in the permission of access. 

2. Deny-biased PEP: if the decision from PDP is permit, then the PEP shall permit 
the access. All other decisions shall result in the denial of access. 

In this case, there is a possibility that an intruder can get an access unintentionally 
by trying to query so that the response is no policy is applicable. Using Permit-biased 
PEI) the decision will let the intruder have access to the system. 

Analysing Conflicting Policies. Conflicting policies can have serious consequences 
and may lead to unauthorized access. Basically, in XACML, conflicting decision 
never occurs since all policies are combined with a particular combining algorithm 
that only returns one decision. However it is interesting to analyse conflict in between 
policies for example different department can have different decision. By analysing 
conflict, the policy makers can rethink again whether they made correct policies. 

Analysing Unreachable Policies. Analysisng unreachable policies helps policy admin¬ 
istrators to reduce the size of the set of policies. A policy is unreachable if for all 
request it never gives decision i.e., either it always not applicable or there is another 
policy that overrides its decision. It is safe to remove unreachable policies because 
their decisions never influence the final decisions. 

To address the above concern we propose a logic-based XACML analysis frame¬ 
work using logic programs (LPs) and answer set semantics. Answer Set Program¬ 
ming (ASP) has become a popular approach to solve combinatorial problems de- 
claratively. There are several efficient implementations of answer set solvers, such 
as ASSAT^, clasp"^, Cmodels^, SmodeLs®, and many more. We present in this paper 
a method using ASP to solve those problems explained previously in the context of 
XACML 3.0 [5], the most recent version of XACML. 

^ http://assat.cs.ust.hk/, 
http: //WWW. cs. uni - potsdam.de/clasp/ 

^ http: //WWW. cs.utexas.edu/users/tag/cmodels/ 

® http://www.tcs.hut.fi/Software/smodels/ 
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Outline. In this paper first we explain the model and semantics of XACML 3.0 in 
Sect. 2. Then we describe the mapping of XACML 3.0 components into logic pro¬ 
grams Vxacml ir* Sect. 3. Next we show how to analyse access control policies such 
as incompleteness, conflicting and reachability XACML policies in Sect. 4. We end 
the paper with conclusion and future work. 


2 XACML Model and Semantics 

In this section we briefly describe the XACML policy language and XACML query 
language model. First we show the faithfully abstract syntax XACML 3.0. Then we 
present a semantics of XACML 3.0 without considering indeterminate values. Our 
argument is that we evaluate access control properties to a set of policies in stat¬ 
ically. Hence, indeterminate values which only occur when there are errors during 
evaluation process do not give impact to our analysis. At the end of this section we 
show the semantics of XACML combining algorithms which are used for composing 
several access control policies. 


2.1 Abstract S 5 nitax of XACML 3.0 

We summarize the S 5 mtax of XACML 3.0 in Table 1. To make the notation clear 
we use bold font for non-terminal S 5 mibols, typewriter font for terminal symbols 
and identifiers and values are written in italic font. Moreover, <XACML Component> 
denotes the S 5 mibol for XACML component. We use the star symbol (*) to indicate 
that there is zero or more of the preceding element and we use the plus S 5 mibol C") 
to indicate that there is one or more of the preceding element. We assume that each 
policy must have a unique identifier (ID). 


Table 1. Abstraction of XACML 3.0 Components 



XACML Policy Components 

<PolicySet> 

- PolicySetID = [<Target>,'«: PolicySetID* », CombID ] 


1 PolicySetID = [<Target>, •*: PolicylD* », CombID ] 

<Policy> 

- PolicylD = [<Target>, <c PolicySetID'^ » CombID ] 

<Rule> 

- RulelD = [ Effect, <Target> , <Condition> ] 

<Condition> 

- propositional formulae 

<Target> 

- Null 


1 /\ <Any0f> ^ 

<Any0f> 

- V <All0f> + 

<All0f> 

- /\ <Match> + 

<Match> 

- Attriypei attribute value ) 

CombID 

- po 1 do 1 fa 1 ooa 

Effect 

- deny | permit 

Attriype 

- subject 1 action | resource | environment 


XACML Request Component 

<Request> 

- { Attribute ■'■} 

Attribute 

- Attriypei attribute value ) \ external state 
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There are three levels of policies in XACML, namely <PolicySet>, <Policy> 
and <Rule>. <PolicySet> or <Policy> can act as the root of a set of access control 
policies while <Rule> is a single entity that describes one particular access control 
policy. Through this paper, we assume that <PolicySet> is the root of the set of 
access control policies. 

<PolicySet> and <Policy> have the same characteristic, i.e., they are contain¬ 
ers for a sequence of <PolicySet>, <Policy> or <Rule>. A <PolicySet> contains 
either a sequence of <PolicySet> or a sequence of <Policy> while a <Policy> 
only can contains a sequence of <Rule>. The sequence of <PolicySet>, <Policy> 
or <Rule> is combined with a particular combining algorithm. There are four com¬ 
mon combining algorithms defined in XACML 3.0, namely permit-overrides (po), 
deny-overrides {do), first-applicable (fa) and only-one-applicable (ooa). 

A <Rule> describes an individual access control policy. It regulates whether 
an access should be permitted or denied. All <PolicySet>, <Policy> and <Rule> 
are applicable whenever their <Target> matches with the <Request>. When the 
<Rule>’s <Ta rget> matches with the <Request>, then the applicability of the <RuLe> 
is refined by its <Condition>. 

A <Target> is a combination of <Match> elements. Each <Match> element de¬ 
scribes an attribute that a <Request> should match in order to activate a policy. 
There are four attribute categories in XACML 3.0, namely subject attribute, action 
attribute, resource attribute and environment attribute. The subject attribute is the 
entity requesting access, e.g., a file system, a workstation, etc. The action attribute 
defines the t)q)e of access requested, e.g., to read, to write, to delete, etc. The re¬ 
source attribute is a data, service or system components. The environment attribute 
can optionally provide additional information. 

A <Request> contains a set of attributes information about access request. A 
<Request> can contain additional information such as external state condition (e.g. 
the current time, current temperature, etc). 


2.2 XACML 3.0 Formal Semantics 


The evaluation of XACML policies against a given request starts from the evaluation 
of <Match> elements and continued bottom-up until the evaluation of <PoLicySet> 
as the root element. We use the [[.]] notation to map XACML elements into their 
values (see the summary in Tabel 2). 

Table 2. XACML Components’ Values 


XACML Components 

Values 

[[<Match>]], [[<All0f>]], 

[[<Any0f>]], [[<Target>]] 

match (m) and not match (nm) 

[[<Condition>]] 

tme (t) and false (f) 

[[<Rule>], [[<Policy>], 
[[<PolicySet>]] 

permit (p), deny (d) and not applicable (na) 




Title Suppressed Due to Excessive Length 


5 


Evaluation of <Match> into {m,nm}. Given a <Request> Q, the evaluation of 
<Match> M is as follows 




m if M e Q 
nm if M 


( 1 ) 


Evaluation of <AllOf> into {m,nm}. Given a <Request> Q, the evaluation of 
<AllOf> A = M; is as follows 


lAMQ) 


m if Vi : [[M;]] = m 
nm if 3i: [[M;]] = nm 


( 2 ) 


where each M; is a <Match> element. 

Evaluation of <AnyOf> into {m,nm}. Given a <Request> Q, the evaluation of 
<AnyOf> E = VlLi A' follows 


lEMQ) 


m if 3i: [[A;]] = m 
nm if Vi: [[A;]] = nm 


(3) 


where each A; is a <AllOf> element. 

Evaluation of <Target> into {m,nm}. Given a <Request> Q, the evaluation of 
<Target> T = /\"^2 A follows 


UMQ) 


m if Vi : [[E;]] = m or T = Null 
nm if 3i: [[E;]] = nm 


(4) 


where each E; is a <AnyOf> element. Empty <Target>, indicated by Null always 
evaluated to m. 

Evaluation of <Condition> into {t,f}. Given a <Request> Q, the evaluation of 
<Condition> C is as follows 


[C](Q) = eval(C,Q) 


(5) 


Note: The eval is an unspecified function that returns {t, f}. 

Evaluation of <Rule> into {d, p, na}. Given a <Request> Q, the evaluation of 
<Rule> R = [e, T, C] as follows 


IRMQ) 


e if [[r](Q) = mand [[C](Q) = t 

na if ([r](Q) = m and [C](Q) = f) or[[r](Q) = nm 


( 6 ) 


where e e { p,d }, T is a <Target> element and C is a <Condition> element. 

Evaluation of <Policy> into {d,p,na}. Given a <Request> Q, the evaluation of 
<Policy> P = [r,< k:Pi,...,R„ »,ComblD] is as follows 


IPMQ) 


na if [[r]](Q) = nm or Vi: [[Ri]](Q) = na 

0combiDCR) otherwise 


(7) 
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where T is a <Target> element, and each R; is a <Rule> element. We use R to 
denote «; [R J (Q),..., [[R„] (Q) ». 

Note: The combining algorithm denoted by 0combiD ^e explained in Sect. 2.3. 

Evaluation of <PolicySet> into {d,p, na}. Given a <Request> Q, the evaluation 
of <PolicySet> PS = [T ,«: R^,.. .,P„ »,ComblD] is as follows 


IPSMQ) 


na if [[r]](Q) = nm or Vi: [[R;]](Q) = na 

0combiD(P) otherwise 


( 8 ) 


where T is a <Target> element and each P; is a <Policy> (or <PolicySet>) ele¬ 
ment. We use P to denote «: [[P^]] (Q),..., [[P„]] (Q) ». 


2.3 XACML Combining Algorithms 

There are four common combining algorithms defined in XACML 3.0, namely permit- 
overrides (po), deny-overrides (do), first-applicable (fa) and only-one-applicable 
(ooa). The permit-overrides combining algorithm takes permit decision as the most 
priority than deny decision while the deny-overrides combining algorithm takes 
deny decision over permit. Likewise their names, the first-applicable combining al¬ 
gorithm return the first <Rule> (or <Policy> or <PolicySet>) that is applicable 
(either permit (p) or deny(d) value) and the only-one-applicable combining al¬ 
gorithm return a decision whenever only one <Rule> (or <Policy> or <PolicySet>) 
which is applicable, otherwise it returns not applicable (na). 


Permit-Overrides The permit-overrides combining algorithm is intended for those 
cases where a permit decision should have priority over a deny decision. 

Let S =<sc Vj, V 2 ,..., v„ » be a sequence of policy values. The permit-overrides 
combining algorithm, 0po, is defined as follows 


p if 31 : V; = p 

^(S) = < d if Vi: V; 7 ^ p and 3; : = d 

P° na otherwise 


(9) 


Deny-Overrides The deny-overrides is the mirror of permit-overrides whereas the 
deny decision has more priority over a permit decision. 

Let S =«: Vi,V 2 ,...,v„ » be a sequence of policy values. The deny-overrides 
combining algorithm, 0^^^, is defined as follows 

d if 31 : Vj = d 
p if VI: V; 7 ^ d and 3; : = p 

na otherwise 


0(S) = 


( 10 ) 
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First-Applicable The result of first-applicable algorithm is the first Rule, Policy or 
PolicySet element in the sequence whose is applicable. 

Let S =«: Vi,V 2 ,...,v„ » be a sequence of policy values. The first-applicable 
combining algorithm, 0fa, is defined as follows 


0(S) = 


na 


if 3i : Vj 7 ^ na and V; : j < i => Vj = na 
if Vi: V; = na 


( 11 ) 


Only-One-Applicable The result of the only-one-applicable combining algorithm 
ensures that one and only one policy is applicable. If no policy applies, then the 
result is na, but if more than one policy is applicable, then the result is idt. When 
exactly one policy is applicable, the result of the combining algorithm is the result 
of evaluating the single applicable policy. Please note that we do not use idt in this 
step. Hence, all of idt value is converted to na. 

Let S =«: v^, V 2 ,..., Vn » be a sequence of policy values. The only-one-applicable 
combining algorithm, 0ooa’ defined as follows 

if 3i : V; 7 ^ na and V; : ; 7 ^ i => Vj = na 
if (3i, j : i 7 ^ j and V; 7 ^ na and Vj 7 ^ na) or (12) 

if Vi: V; = na 


0(S) = 


Vi 

na 


3 Mapping XACML into Logic Programs 

First we explain the syntax of logic program (LP) in this section. Then we show the 
transforming XACML 3.0 into LR The semantics of LP is explained in the following 
section when we use it for analysis purposes. 

3.1 Syntax of Logic Programs 

We start by introducing some notations and terminologies which we will use through 
the paper. First-Order Language. We consider an alphabet consisting of (finite or 

countably infinite) disjoint sets of variables, constants, function S 5 mibols, predicate 
symbols, connectives {not,A,«—}, punctuation symbols and spe¬ 

cial S 5 mibols { T, ± }. In this paper we will use upper case letters to denote variables 
and lower case letters to denote constants, function and predicate S 5 mibols. Terms, 
atoms, literals and formulae are defined as usual. The language given by an alpha¬ 
bet consists of the set of all formulae constructed from the symbols occurring in the 
alphabet. 

Logic Programs. A rule is an expression of the form 

A<— Bj A ... AB„, A not A ... A not B„. (13) 

where A is either an atom or ± and each B;, 1 < i < n, is an atom or T. T is a valid 
formula. A is called the head and Bj A ... A B„, A not B„,+i A ... A not B„ is called 
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body of the clause. We usually write A ... A A not 5^+1 A ... A not simply 

as Bj, ...not B^+j,...,not B„. 

We refer the rule as a constraint when A is _L. One should observe that the body 
of a rule must not be empty. A rule of the form A <— T is called a fact. 

A logic program (LP) is a finite set of rules. ground(V) denotes the set of all 
ground instances of the program V. 

3.2 XACML Transformations 

The transformation of XACML components is based on the semantics of each com¬ 
ponent explained in Sect. 2.2. First we recall the syntax of each component then we 
show how the transformation is. 

<Request> Transformation. XACML Syntax: Let Q = {Ai,...,A„ },1 < i < n, be 
a <Request> component. The transformation of <Request>, Q, into LP Vq is as 
follows 

A; ^ T. 1 < i < n 

<Match> Transformation. XACML Syntax: Let M be a <Match> component. The 
transformation of <Match> M into LP Vm is as follows (see (1) for <Match> evalu¬ 
ation) 

val(M,m) <—M. 
val(M, nm) <— not M. 

<AllOf> Transformation. XACML Syntax: Let A = /\"^j M; be an <AllOf> compon¬ 
ent where each M; is a <Match> component. The transformation of <AllOf> A into 
LP Va is as follows (see (2) for <AllOf> evaluation) 

val(A,m) <— val(Mi,m),...,val(M„,m). 
val(A, nm) <— valCM;, nm). (1 < i < n) 

<AnyOf> Transformation. XACML Syntax: Let E = VlLi^i an <AnyOf> compon¬ 
ent where each A, is an <AllOf> component. The transformation of <AnyOf> E into 
LP Ve is as follows (see (3) for <AnyOf> evaluation) 

val(B, m) «—val(Ai, m). (1 < i < n) 
val(B,nm) <— val(Ai, nm),..., val(A„,nm). 

<Target> Transformation. XACML Syntax: Let T = be a <Target> com¬ 

ponent where each B; is an <AnyOf> component. The transformation of <Target> 
T into LP Vf is as follows (see (4) for <Target> evaluation) 

val(T, m) <— val(Bi, m),..., val(B„, m). 
val(nun,m) <— T. 

val(T, nm) <— val(Bi, nm). (1 < i < n) 

<Condition> Transformation. XACML Syntax: We assume that the <Condition> 
element is a boolean formula which the evaluation of <Condition> is based on eval 
function. The transformation of <Condition> C into LP Vc is as follows 


val(C,y) ^eval(C,V). 
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In our previous example of <Rule> rl, the <Condition> cond(rl) is patient. id (X) 
/\ patient-record. id(X). The possibility of eval function is like following 

'^cond(rl) * 

val(cond(rl), V) <— eval(cond(rl), V). 

eval(cond(rl),t) <— patient_id(X),patient_record_id(X'). 
eval(cond(rl),f) patient_id{X),patient_record_id{Y),X 7 ^ Y. 

The emr{patient_id[X)) and emr[patient_recordjid[X)) indicate possible er¬ 
rors might occur, e.g., the system could not connect to the database so that the 
system does not know the ID of the patient. 

<Rule> Transformation. X4CML Syntax: LetR^^j = [E, T, C] be a <Rule> component 
where £ e { p,d }, T is a <Target> and C is a <Condition>. The transformation of 
<Rule> Ri^ into LP is as follows (see ( 6 ) for <Rule> evaluation) 

val(Rid,£) «—val(T, m),val(C,t). 
val(Rid>na)«— val(T, m), val(C,f). 
val(Rid, na)«— val(T, nm). 

<Policy> Transformation. XACML Syntax: Let = [T,«: Rj,... ,R„ », CombID] 
be a <Policy> component where T is a <Target>, < Ri,...,R„ > be a sequence 
of <Rule> elements and CombID be a combining algorithm identifier. In order to 
indicate that the <Policy> contains <Rule> R;, thus for every <Rule> R; contained 
in R,d = [T ,«: Rj,... ,R„ », CombID], Vp.^ also contains: 

dec(Pid,Ri,R) ^ val(Ri,R). (1 < i < n) 

Next, we do a transformation for <Policy> Pid and add into LP Vp.^ is as follows 
(see (7) for <Policy> evaluation) 

val(Pjd, na)«— val(r, nm). 

val(Pid, na) <— val(Ri, na),..., val(R„, na). 

val(Pid,£) <—val(r, m),dec(Pid,R, y), V / na, algo(ComblD,P;d,R). 

We write formulae dec(Pi;j,R, V), V 7 ^ na to make sure that there is a <Rule> in 
the <Policy> that is not evaluated to na. We do this to avoid a return value from 
a combining algorithm that is not naeven tough all of the <Rule> elements are 
evaluated to na. 

<PolicySet> Transformation. The transformation of <PolicySet> is similar to the 
transformation of <Policy> component. 

XACML Syntax: Let PSj^j = [£,<*: Pj,...,P„ »,CombID] be a <Policy> com¬ 
ponent where T is a <Target>, < Pi,...,P„ > be a sequence of <Policy> (or 
<PolicySet>) elements and CombID be a combining algorithm identifier. The trans¬ 
formation of <PolicySet> PSi^ into logic program VSp.^ is as follows For every 
<Policy> (or <PolicySet>) contained in PS,-^ = [T,Pj,...,P„ »,CombID], 
Vps.^ also contains: 

dec(PSid,Pi,R) - val(Pi,£). (1 < i < n) 
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And we following rules into Vps.^ 

val(PSid, na)«— val(r, nm). 

val(PSid, na)«— val(Pi, na),..., val(P„, na). 

val(PSid,£) <—val(T, m),dec(PSid,P, V), V 7 ^ na, algo(ComblD,PSid,P). 


3.3 Combining Algorithm Transformation 

We use P for an variable of <Policy> identifier and R, and R 2 for variables 
of <Rule> identifiers. In case the evaluation of <PolicySet>, the input P is for 
<PolicySet> identifier, R,Ri and R 2 are for <Policy> (or <PolicySet>) identifiers. 

Permit-Overrides Transformation. Let Vp^ be a LP obtained by permit-overrides 
combining algorithm transformation (see (9) for the permit-overrides combining 
algorithm semantics). Vp^ contains: 

algo(po,P,p) ^dec(P,P,p). 

algo(po,P,d) «— not algo(po,P, p),dec(P,R,d). 

algo(po, P, na)«— not algo(po, P, p), not algo(po, P, d). 

Deny-Overrides Transformation. Let P be a LP obtained by deny-overrides com¬ 
bining algorithm transformation (see ( 10 ) for the permit-overrides combining al¬ 
gorithm semantics). Vp^ contains: 

algo(po,P,d) «—dec(P,P,d). 

algo(po,P, p) «— not algo(po,P,d),dec(P,R, p). 

algo(po, P, na)«— not algo(po, P, d), not algo(po, P, d). 

First-Applicable Transformation. Let 7^,3 be a logic program obtained by first- 
applicable combining algorithm transformation (see ( 11 ) for the first-applicable 
combining algorithm semantics). For each <Policy> (or <PolicySet>) which uses 
first-applicable combining algorithm, P;j = [T,«:Pj ,...,Rn »,fa], Vp.^ contains: 

algo(fa,P,P) <— dec(P,Pi,P),P 7 ^ na. 
algo(fa,P,P) <— dec(P,Pi, na),dec(P,P 2 >^)>^ ^ na. 

algo(fa,P,P) <— dec(P,Pi,na),...,dec(P,R„_i,na), 
dec(P,P„,£). 

Only-One-Applicable Transformation. Let be a logic program obtained by 
only-one-applicable combining algorithm transformation (see ( 12 ) for the only-one- 
applicable combining algorithm semantics). contains: 

not_one_applicable{P) <— dec(P,Rl,X),dec(P,R2,7),R1 ^R2,X ^ na,Y 7 ^ na. 
algo(ooa,P,R) «— dec(P,R,R),not not_one_applicable{P). 

algo(ooa, P, na) <— not_one_applicable{P). 
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4 Policy Analysis 

We use the semantics of LP Vxacml - the result from transforming XACML compon¬ 
ents into series of LPs - to analyse access control policy properties. In this section, 
we present three policy analysis cases namely analysing on incompleteness policies, 
conflicting policies and unreachable policies. The completeness and free of conflict 
properties have been introduces by Samarati and di Vimercati in [7] and formal¬ 
ized using Belnap four-valued logic [2] by Bruns and Huth in [3]. In this section 
we show how we present ASP programs to capture those properties^. Our intention 
is to have an automatic tool that shows XACML formalization and in the same time 
it can be used to help policy administrators to analyse their policies sets. 

4.1 Semantics of Logic Programs 

The declarative semantics of a logic program is given by a model-theoretic semantics 
of formulae in the underlying language. The formal definition of answer set se¬ 
mantics can be found in many literatures like in [1,4]. 

Interpretations and Models The Herbrand Universe Ui;^ for a language C is the 
set of all ground terms that can be formed from the constants and function S 5 mibols 
appearing in C. The Herbrand base for a language £ is the set of all ground atoms 
that can be formed by using predicate S 5 nnbols from £ and ground terms from 
as arguments. By Bj, we denote the Herbrand base for language underlying the 
program V. When the context is clear, we are safe to omit V. 

An interpretation 7 of a program V is a mapping from the Herbrand base B-p to 
the set of truth value true and false ({ T, ± }). All atoms belong to interpretation I 
are mapped to T. All atoms which does not occur in I are mapped to _L. 

The truth value of arbitrary formulae under some interpretation can be determ¬ 
ined from a truth table as usual (see Table 3). 

Table 3. Truth Values for Formulae 


4> 

xp 

not (p 

(p Alp 

(P^iP 

T 

T 

1 

T 

T 

T 

1 

1 

1 

T 

1 

T 

T 

1 

1 

1 

1 

T 

1 

T 


The logical value of ground formulae can be derived from Table 3 in the usual 
way. A formula (p is then true under interpretation I, denoted by 7((^) = T, if all its 
ground instances are true in 7; it is false under interpretation 7, denoted by 7(^) = _L, 
if there is a ground instance of cp that is false in 7. 

Let 7 be an interpretation. 7 satisfies formula cp, denoted by 7 |= <^, if 7(^) = T. 
For a program V, we say 7 satisfies of V, denoted by 7 |= V, if 7 satisfies for every 
clause in V. 

^ We call ASP programs for logic programs with answer set semantics. 
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Let I be a collection of interpretations. Then an interpretation 7 is I is called 
minimal in I if and only if there is no interpretation J in I such that J c 7 . An 
interpretation 7 is called least in I if and only if 7 c j for any interpretation J in 
I. A model M of a program V is called minimal (respectively least) if it is minimal 
(respectively least) among all models of V. 

The answer set semantics of logic program V assigns toV a collection of answer 
sets - interpretations of ground(P). An interpretation 7 of ground{V) is an answer 
set for T* if 7 is minimal (w.r.t. set inclusion) among the interpretations satisfying 
the rules of 


A<-Bi,...,B^,notB^+i,...,notB„ ePand 
7(not B^+i,.. .,not B„) = true] 

A logic program can have a unique, many or none answer set(s). Therefore, we 
show that programs with a particular characteristic are guaranteed to have unique 
answer set. 

Acyclic Programs. We say that a program is acyclic when there is no cycle in the 
program.The acyclicity in the program is guaranteed by the existence of a certain 
fixed assignment of natural numbers to atoms that is called a level mapping. 

A level mapping for a program P is a function 

/ : Bp ^ N 

where N is the set of natural numbers and B-p is the Herbrand base for V. We 
extend the definition of level mapping to a mapping from ground literals to natural 
numbers by setting Z(not A) = Z(A). 

Let The a logic program and I be a level mapping for V. V is acyclic with respect 
to I if for every clause A«— Bj,..., not not B„ in groundfV^ we find 

Z(A) > Z(Bj) for all i with 1 < i < n 

V is acyclic if it is acyclic with respect to some level mapping. 

Acyclic programs are guaranteed to have unique answer sets [1]. 


4.2 XACML Semantics Based On ASP Semantics 

We can see from Sect. 3 that all of the XACML 3.0 transformation programs are 
acyclic. Thus, it is guaranteed that Vxacml has unique answer set. 

Proposition 1. Let Vxacml he u program obtained from XACML 3.0 element trans¬ 
formations and let Vq be a program transformation of <Request> Q. Let I be the 
answer set of Vxacml ^ ^q- Then the following equation holds 


[X](Q) = Vijfval(X,V)e7 
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4.3 Analysis on Incompleteness Policies 

A set of policies is complete if it always returns a decision given for any request. 
XACML defines that there is one <PolicySet> as the root of a set of policies. There¬ 
fore, we formally express completeness property as follows: 

complete: VQ : [PS„ot](Q) ^ na 

where Q for <Request> and is the root of <PolicySet> element in the set of 

policies. 

We say that there is a gap in the policy set if it is not complete. Hence, we 
formally express gap property as follows: 

gap: -^complete 


It is equal to 

gap: 3Q: ] (Q) = na 

The idea of having gap property is to have a logic program that can show answer 
sets whenever there is gap in the policies. We use the answer sets as the witnesses 
of the incompleteness policies. 

In order to check gap property we should generate all possible values restored 
in the database for each attribute. Each attribute only possible to have one value. 
Thus, we use cardinality constraint [8,10] and the encoding is as follows: 


V 

• generate_one • 

llsubjectiX) : subjectjlbiX)}! «— T. 

l{action(X) : action_db(X)}l «—T. 

l{resource(X) : resource_db(X)}l «— T. 

l{environment{X) : environment_db(X')}l «— T. 


The intuitive meaning of the above cardinality constrains is that, for each subject in 
the database, exactly one instance of subject request is generated. The conversion 
holds for other attributes. 

We say there is a gap whenever we can find a request that makes value of the 
PS^ggi- is na. Here is the encoding: 

V 

/^gap ■ 

gap ^ val(PS„ot,na). 

_L «— not gap. 

We force ASP solver to find a gap by putting a constraint _L «— not gap. 

The answer sets of program V = Vxacml ^ Vg^nerate one U Vgap are the witnesses 
that the set of policies encoded in Vxacml incomplete. When there is no model 
satisfies the program then we are sure that the set of policies captures all of possible 


cases. 
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4.4 Analysis on Conflicting Policies 

A conflict never occurs in XACML because the structure of policies where there 
is only one <PolicySet> as the root of all of policies and all of others policies 
are combined by combining algorithm. Each combining algorithm returns a single 
decision either permit or deny and never return both decisions in the same time. 
However, it is still interesting to know whether there are two <Rule> give conflict 
decisions. We formally define a conflict is as follows: 

conflict: 3Q : IRJ (Q) = p A IR'J (Q) = d 

In order to compute whether there is a conflict in the set of policies, we encode a 
logic program for conflict property as follows: 

'^conflict * 

conflict «— val(R, p), val(R', d),R ^ R'. 

_L «— not conflict. 

The same as gap condition, we force ASP solver to find a conflict by putting a 
constraint ± <— not conflict. 

A conflict can be analysis whenever V = Vxacml U Vgemrate one U 'Pconfiict returns 
answer sets. The returning models are evidences where the conflict between <Rule> 
occurs. We conclude that a set of policies is conflict-free if and only if program V is 
unsatisfied, i.e., there is no returned model. 

4.5 Analysis on Reachability Policies 

A policy is reachable if there is a request such that the decision is made based on 
this policy. Usually in a big set of policies, there is a policy that is not reachable. 
This happens because policies are built based on several components and combined 
together. We formally define a reachability property as follows: 

reachable(R): 3Q : [[RKQ) 7^ ria. 

where Q is <Request> element and R is <Rule> element. 

The encoding of reachability property in logic program is as follows: 

'^reachable • 

reachable(R} <— val(R, £),£ ^ na. 

Formally, a policy is not reachable if for every request either: 

1. It always return na. 

unreachable(R): VQ : [[R]] = na 

2 . in case of permit-overrides combining algorithm, a policy is not reachable if its 
decision is deny but the final decision of the root policy is permit. 

unreachable: VQ : [[R]] = d A [[R]] (Q) = p 


where inP = [T,<sc ...,R,... »,po] 
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3. In case of deny-overrides combining algorithm, a policy is not reachable if its 
decision is permit but the final decision of the root policy is deny. 

unreachable(R): VQ : [[R]] = p A [[Pj (Q) = d 
where in P = [T, <s;... ,R,... »,do] 

4. In case of only-one-applicable combining algorithm, a policy is not reachable if 
it is applicable policy but the final decision of the root policy is not applicable. 
This indicates that there is another policy that is also applicable. 

unreachable(R): VQ : [[R]] 7 ^ na A [[P]] (Q) = na 
where in P = [T,«:... ,R,... », 00 a] 

5. In case of first-applicable combining algorithm, a policy is not reachable if it is 
applicable but there is another policy in the same collection that is in the earlier 
of the sequence that is also applicable. 

unreachable(Rj): VQ : 7 ^ na A [[R;]] (Q) 7 ^ na A i < ; 

where in P = [T,«:... ,Rj,... ,Rj,... »,fa] 

First of all we should generate all possible attributes. This time, the encoding 
is different with program Vgenerate one because we want to generate all possible at¬ 
tributes, not only one. Hence, we do not use cardinality constraint in this encoding. 
Here is the encoding: 

'^generate_aU • 

subject^X) ^ subject_db{X). 

actionjX) ^ action_db{Xj. 

resourcejX) ^ resource_db{Xj. 

environmentjX) <— environmentjibiX). 

Following we translate each unreachable condition into logic program 

'^not_reachable * 

not_reachable[Rj «— not reachable[Rj. 
not_reachable{R) «— val(P, p), dec(P,R, d). 
not_reachable{R) «— val(P, d), dec(P,R, p). 
not_reachable{R) «— val(P, na),dec(P,R,R),R 7 ^ na. 

In the case of first-applicable combining algorithm, there is a possibility a policy 
returns permit and the final decision is also permit, but, the permit of the final 
decision comes from the earlier applicable policy. Hence, we should take care of 
the ordering of policies. We need to add extra rules in the program transformations 
such as: for every <Rule> R; contained in Pid = Ri,...,Rn »,fa], Vp.^ also 

contains: 


dec(Pid,Ri,£,/) val(Ri,£). (1 < i < n) 
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Here we add to our Vnotj-^achabu 

notj-eachable{Rj) «— deciPi^,Ri,E,I'),6eciPi^,Rj,E',J'),E ^ na,£' 7 ^ na,/ < J. 

To check unreachable property we add to our program Vnot reachable ■ 

not_reachable <— notj-eachableiK). 

_L <— not not_reachable. 

We force ASP solver to find unreachable policies by putting a constraint ± <— 
not not_reachable. When not_reachable{R) is in the answer set of V = Vxacml 
'P generate_all U Vreaehable U Kot_reaehable then it iS Safe tO remove poHcy R from the Set 
because it is unreachable. 

5 Conclusion and Future Work 

We have shown a mechanism to map XACML 3.0 components into logic programs. 
Using the advantages of ASP technique to solve combinatorial problems efficiently 
we have presented ASP programs to capture analysing in access control policies 
incompleteness property, conflicting property and unreachability property. Our in¬ 
tention is to have an automatic tool that both showing formalization and also help 
policy administrators to analyse their policies sets. 

For future work, we would like to analyse conflict in attribute based like in 
Singh’s work [9]. We also would like to extend our work to handle Role-Based 
Access Control (RBAC) [6] and see the conflict might occurs between different 
roles. 

In order to reduce the policies, we could inspect redundancy between policies. 
We should find a subset of policies that might capture the whole possible decisions 
might happen in all policies. Thus, we could have smaller set than the original 
policies set. 
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